home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-07-15 | 101.5 KB | 2,773 lines |
- The drawings contained in this Recommendation have been done in Autocad
- Recommendation X.311)
- SUPPORT OF PACKET MODE TERMINAL EQUIPMENT BY AN ISDN
- (Malaga-Torremolinos, 1984; amended at Melbourne, 1988)
- The CCITT,
- considering
- (a) that DTEs conforming to Recommendation X.25 will be used, at least
- during the evolution of integrated services digital networks (ISDN) and possibly thereafter, in conjunction
- with packet switched data transmission services (PSDTS) provided on
- an ISDN or via an ISDN to PSPDNs;
- (b) that packet-mode TE1s conforming to the I-series
- Recommendations (I.430/I.431) at reference points S and T will be
- used in conjunction with PSDTS provided by an ISDN or via an ISDN
- to PSPDNs;
- (c) that the functions and protocol defined by this
- Recommendation must allow the provision of the network service
- defined in Recommendation X.213;
- (d) that the interworking function between an ISDN and a
- PSPDN is defined in Recommendation X.325;
- (e) that the demand access to PSPDNs is defined in
- Recommendation X.32;
- (f) that the dedicated access to PSPDNs is defined in
- Recommendation X.25,
- unanimously declares
- that the following should apply for the support of packet-mode terminal
- equipment by an ISDN.
- This Recommendation addresses the following aspects:
- (1) definition of the aspects of the packet-mode services provided to the
- ISDN users in accordance with the bearer services defined in I-series
- Recommendations;
- (2) definition of the procedures at the ISDN user-network interface for
- accessing packet-mode services in alignment with Recommendations I.430,
- I.431, Q.921 and Q.931;
- (3) definition of the TA's functions for adapting existing X.25 terminals.
- PADs may be supported within the network, in which case existing
- Recommendations shall apply for asynchronous access (e.g., X.3, X.28, X.29,
- X.52). The support of asynchronous access by an ISDN or through an ISDN is not
- within the scope of this Recommendation.
- CONTENTS
- 1 General service aspects
- 2 Reference configurations
- 2.1 Configuration when accessing PSPDN services (Case A)
- 2.2 Configuration for the ISDN virtual circuit service (Case B)
- 3 Service aspects
- 3.1 Access to PSPDN services (Case A)
- 3.1.1 Service characteristics
- 3.1.2 User access capabilities
- 3.1.3 Basic rules
- 3.1.4 Notification classes
- 3.2 Access to the ISDN virtual circuit service (Case B)
- 3.2.1 Service characteristics
- 3.2.2 User access capabilities
- 3.2.2.1 Access through the B-channel
- 3.2.2.1.1 Service limitations
- 3.2.2.1.2 Basic rules
- 3.2.2.2 Access through the D-channel
- 3.2.2.2.1 Service limitations
- 3.2.2.2.2 Basic rules
- 3.2.3 Notification classes for incoming calls
- 3.2.3.1 No notification class
- 3.2.3.2 Conditional notification class
- 3.2.3.3 Unconditional notification class
- 3.2.3.4 Information mapping from the X.25 incoming call packet to
- 1) This Recommendation is also included in the Recommendations of the I-series under
- the number I.462.
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- the Q.931 message
- 3.3 Compatibility checking
- 4 Addressing and routing aspects
- 4.1 Terminal interface selection
- 4.2 Access to PSPDN services (Case A)
- 4.2.1 Channel type selection
- 4.2.2 Addressing scheme for outgoing calls
- 4.3 Access to the ISDN virtual circuit service (Case B)
- 4.3.1 Channel type selection
- 4.3.2 Addressing scheme for outgoing calls
- 5 Interworking with dedicated networks
- 5.1 Circuit-mode access to PSPDN services (Case A)
- 5.2 Access to PSPDNs via virtual circuit service (Case B)
- 6 Packet communications at the S/T reference point
- 6.1 Outgoing access
- 6.1.1 Circuit-switched access to PSPDN services (Case A)
- 6.1.2 Access to the ISDN virtual circuit service (Case B)
- 6.1.2.1 B-channel
- 6.1.2.2 D-channel
- 6.2 Incoming access
- 6.2.1 Access from PSPDN services (Case A)
- 6.2.1.1 General
- 6.2.1.2 Channel negotiation
- 6.2.2 Access from the ISDN virtual circuit service (Case B)
- 6.2.2.1 B-channel
- 6.2.2.2 D-channel
- 6.2.2.3 Call offering
- 6.2.2.3.1 Channel selection through call offering
- 6.2.2.3.2 Information element mapping
- 6.2.2.3.3 Channel selection without call offering
- 6.3 Virtual call establishment and release
- 6.3.1 Link layer establishment and release
- 6.3.2 Packet layer virtual call setup and release
- 6.4 Call clearing
- 6.4.1 B-channel
- 6.4.2 D-channel
- 6.4.3 Additional error handling information
- 6.4.4 Cause mapping
- 6.4.4.1 Access to/from PSPDN services (Case A)
- 6.4.4.2 Access to/from the ISDN virtual circuit service (Case B)
- 6.5 Access collision
- 7 Terminal adaptor functionalities
- 7.1 General
- 7.2 Physical interfaces
- 7.3 Access through the B-channel
- 7.3.1 General
- 7.3.2 Rate adaption
- 7.3.3 Signalling
- 7.3.3.1 Outgoing call
- 7.3.3.1.1 Conditions for initiating B-channel
- establishment
- 7.3.3.1.2 Options for transferring the ISDN address of the
- PSPDN port to the TA
- 7.3.3.1.3 Mapping of procedures
- 7.3.3.1.4 Mapping of Q.931 messages
- 7.3.3.1.5 X.25 procedures
- 7.3.3.2 Incoming call
- 7.3.3.2.1 Q.931 call offering
- 7.3.3.2.2 Actions at the reference point
- 7.3.3.2.3 X.25 procedures
- 7.3.3.3 Call clearing
- 7.3.3.3.1 Initiation of call clearing by the DTE
- 7.3.3.3.2 Initiation of call clearing by the network
- 7.3.3.3.3 Initiation of call clearing by the user
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- 7.3.4 Synchronization
- 7.4 Access through the D-channel
- 7.4.1 General
- 7.4.2 LAPB-LAPD mapping
- 7.4.2.1 Mapping by full link layer termination
- 7.4.2.1.1 Information frame address field mapping
- 7.4.2.1.2 Information frame control field mapping
- 7.4.2.1.3 Information frame check sequence recalculation
- 7.4.2.2 Mapping by minimum link layer termination
- 7.4.3 Signalling
- 7.4.3.1 Outgoing call
- 7.4.3.1.1 Conditions for the establishment of a logical link
- between the DTE and the PH
- 7.4.3.1.2 Mapping of link procedures
- 7.4.3.1.3 X.25 procedures
- 7.4.3.2 Incoming call
- 7.4.3.2.1 Q.931 call offering
- 7.4.3.2.2 X.25 procedures
- 7.4.3.3 Data link disconnection
- 7.4.3.3.1 Disconnection by the PH
- 7.4.3.3.2 Disconnection by the DTE
- 7.5 Access through the B and D channel
- 7.5.1 General
- 7.5.2 Outgoing call
- 7.5.3 Incoming call
- 7.6 Test loops
- 7.6.1 Test loops for TA with access through the B-channel
- 7.6.1.1 Test loop reference configuration
- 7.6.1.2 Test loop characteristics
- 7.6.1.3 Loop activation/deactivation mechanism
- 7.6.1.4 Coding of activation/deactivation control messages
- 7.6.2 Test loops for TA with access through the D-channel
- Appendix I - B-channel TA acting on layer 2 and 3 of X.25
- Appendix II - Interconnection of packet mode TE2s which use the circuit-mode
- bearer service of the ISDN
- Appendix III - Example message flow diagrams and example conditions for cause
- mapping
- Appendix IV - D-channel TAs requiring full protocol termination in the TA
- Appendix V - References
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 1 General service aspects
- Two main services for packet switched data transmission are defined for
- packet-mode terminals connected to the ISDN, namely:
- Case A - access to a PSPDN (PSPDN services);
- Case B - use of an ISDN virtual circuit service.
- The provision of these services is defined in Recommendation I.230 series.
- In Case A an ISDN transparent circuit connection, either permanent (i.e.,
- non-switched) or demand (i.e., switched), is used. The corresponding ISDN bearer
- service is a 64 kbit/s service as described in Recommendation I.231. The service
- available to the user is that of the PSPDN described in X.25 (permanent access)
- and X.32 (demand access), as well as in other X-series Recommendations (e.g.,
- X.2, X.121).
- In Case B an ISDN virtual circuit service is used, as described in
- Recommendation I.231, S 3.2.1. The service available is described in I-series
- Recommendations.
- In Case A only B-channel can be used to access the packet switched service
- at the user-network interface, while in Case B both B- and D-channels can be
- used. The detailed service aspects for both cases are described in S 3.
- This Recommendation covers the following procedures at the S/T reference
- point:
- - B- and D-channel access on both basic and primary rate interfaces.
- Application to H-channel access is for further study.
- - X.25 LAPB procedures on the B-channel and Q.921 LAPD procedures on the
- D-channel. X.25 LAP procedures are not considered here.
- - X.25 packet layer procedures on both B- and D-channels.
- In addition, this Recommendation defines the use of Q.921 and Q.931
- procedures, when appropriate for the establishment and release of a physical path
- through the ISDN.
- 2 Reference configurations
- The configurations given below are the basis on which the support of X.25
- DTEs and TE1s by the ISDN should be standardized. Interworking considerations are
- defined in S 5.
- These configurations are also the basis on which the support of packet
- mode T s by an ISDN has been standardized, since an
- X.25 DTE and its Terminal Adaptor (TA) is always equivalent to a
- packet mode TE1 at the S/T interface. Therefore, every reference in
- this Recommendation to the combination of an X.25 DTE and its TA
- should always be considered as being applicable to a packet mode
- TE1. However, some TE1s may have more capability than that
- available from an X.25 DTE and its TA. Similarly, this
- Recommendation covers the support of NT2s operating in the
- packet-mode.
- Multiple X.25 DTE + TAs or TE1s, or a combination thereof, may
- be supported at the customer premises. Multiple X.25 DTEs may be
- multiplexed at layer 3 by an NT2 onto a single B-channel. Multiple
- TAs or TE1s are able to use the B-channel, one at a time, on a
- per-call basis.
- Note - Multiplexing at layer 2 within a B-channel is for
- further study.
- (
- (i.e., involving either a B- or D-channel).
- 2.1 Configuration when accessing PSPDN services (Case A)
- This configuration (Figure 2-1/X.31) refers to the service of Case A, thus
- implying a transparent handling of packet calls through an ISDN. Only access via
- the B-channel is possible. In this context, the only support that an ISDN gives
- to packet calls is a physical 64 kbit/s circuit-mode semi-permanent or demand
- transparent network connection type between the appropriate PSPDN port and the
- X.25 DTE + TA or TE1 at the customer premises.
- In the case of semi-permanent access, the X.25 DTE + TA or TE1 is
- connected to the corresponding ISDN port at the PSPDN (AU). The TA, when present,
- performs only the necessary physical channel rate adaption between the user at
- the R reference point and the 64 kbit/s B-channel rate. Q.931 messages are not
- used in this case.
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- Fig. 2-1/X.31/T0700901-88 = 15 cm
-
- In the case of demand access to PSPDNs, which is illustrated in the upper
- portion of Figure 2-1/X.31, the X.25 DTE + TA or TE1 is connected to an ISDN port
- at the PSPDN (AU). The AU is also able to set up 64 kbit/s physical channels
- through the ISDN.
- In this type of connection, originating calls will be set up over the
- B-channel towards the PSPDN port using the ISDN signalling procedure prior to
- starting X.25 layer 2 and layer 3 functions. This can be done by exploiting
- either hot-line ( , direct call) or complete selection
- methods. Moreover, the TA, when present, performs user rate
- adaption at 64 kbit/s. Depending on the data rate adaption
- technique employed, a complementary function may be needed at the
- AU of the PSPDN (see S 7 on TA rate adaption).
- In the complete selection case, two separate numbers are used
- for outgoing access to the PSPDN:
- - the ISDN number of the access port of the PSPDN, indicated in the Q.931
- SETUP message;
- - the address of the called DTE indicated in the X.25 call request
- packet.
- The corresponding service requested in the Q.931 SETUP message is ISDN
- circuit-mode bearer services.
- For calls originated by the PSPDN, the same considerations as above apply.
- In fact, with reference to Figure 2-1/X.31, the ISDN port of the PSPDN includes
- both rate adaption (if required) and path setting-up functions.
- When needed, DTE identification may be provided to the PSPDN by using the
- call establishment signalling protocols in Recommendation Q.931. Furthermore, DCE
- identification may be provided to the DTE, when needed, by using the same
- protocols.
- For the demand access case, layer 2 and layer 3 operation in the B-channel
- as well as service definitions are given in Recommendation X.32.
- Some PSPDNs may operate the additional DTE identification procedures
- defined in Recommendation X.32 to supplement the ISDN provided information in
- Case A.
- 2.2 Configuration for the ISDN virtual circuit service (Case B)
- This configuration refers to the case where a packet handling (PH)
- function is provided within the ISDN. The configuration in Figure 2-2/X.31
- relates to the case of X.25 link and packet level procedures conveyed through the
- B-channel. In this case, the packet call is routed, within an ISDN, to some PH
- function where the complete processing of the X.25 call can be carried out.
- Fig. 2-2/X.31/T0700911-88 = 15 cm
-
- IS
- ISDN implementation alternatives. In any case a BVchannel connection is set up
- to/from a PH port supporting the necessary processing for BVchannel packet calls,
- standard X.25 functions for layer 2 and layer 3 as well as possible path
- settingVup functions for layer 1 and possible rate adaption.
- The configuration in Figure 2V3/X.31 refers to the case of X.25 packet
- layer procedures conveyed through the DVchannel. In this case a number of DTEs
- can operate simultaneously through a DVchannel by using connection identifier
- discrimination at layer 2. The accessed port of PH is still able to support X.25
- packet layer procedures.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- Fig. 2-3/X.31/T0700921-88 = 15 cm
-
- It is also important to note that the procedures for accessing a PSDTS
- through an ISDN user-network interface over a B- or D-channel are independent of
- where the service provider chooses to locate packet handling functions, i.e.:
- a) in a remote exchange or packet switching module in an ISDN;
- b) in the local exchange.
- However, the procedures for packet access through the B-channel or the
- D-channel are different (see S 6).
- In both cases of B- and D-channel accesses, in the service of Case B, the
- address of the called DTE is contained in the X.25 call request packet. The
- establishment of the physical connection from the TA/TE1 to the packet handling
- functions is done on the basis of the requested bearer service (ISDN virtual
- circuit service), therefore, the user does not provide any addressing information
- in the Q.931 procedures.
- 3 Service aspects
- 3.1 Access to PSPDN services (Case A)
- Interworking considerations are defined in S 5.
- 3.1.1 Service characteristics
- In this case, the ISDN offers a 64 kbit/s circuit-switched or
- semi-permanent transparent network connection type between the TA/TE1 and the
- PSPDN port (AU). In the switched access case the AU must be selected by the
- called address in the D-channel signalling protocol when the TA/TE1 sets up the
- circuit-switched connection to the AU. In the non-switched access case, Q.931
- call control messages are not used.
- Since the packet switched service provider is a PSPDN, some DTEs are PSPDN
- terminals; they are handled by the PSPDN. Other DTEs may access the PSPDN without
- subscribing to the PSPDN permanently.
- In the first case, the same services as PSPDN services are maintained,
- including facilities, quality of service (QOS) characteristics and DTE-DCE
- interfaces. In the case where a DTE is not subscribing to the PSPDN, it will be
- provided with a limited set of PSPDN facilities (see Recommendation X.32).
- Every DTE will be associated with one or more ISDN (E.164) numbers. In
- addition, a DTE may be associated with one or more X.121 numbers assigned by the
- PSPDN(s) associated by the DTE. The method for X.25 packets to convey numbers
- from the ISDN numbering plan and the relationship with X.121 are described in
- Recommendation E.166.
- 3.1.2 User access capabilities
- In this case DTEs belonging to user classes of service 8 to 11, 13 and 30
- of Recommendation X.1 (categories of access Q1 to Q5 of Recommendation X.10) can
- be supported with no restrictions on the use of Recommendation X.25. The rate
- adaption mechanism for user classes of services 8 to 11 (categories of access Q1
- to Q4) as well as the TA functionalities are described in S 7.
- 3.1.3 Basic rules
- establ
- established by separating the establishment phase of the BVchannel and the
- control phase of the virtual circuits using the X.25 protocol (link layer and
- packet layer).
- In general ISDN has no knowledge of the customers' terminal equipment or
- configuration. The incoming BVchannel connection establishment will have to
- employ the DVchannel signalling procedure (see Recommenda-tion Q.931).
- 3.1.4 Notification classes
- There is one class in terms of Q.931 procedures to notify the user of
- incoming calls. In addition there is a notification class which does not use
- Q.931 procedures. These two classes may be provided on a subscription basis.
- Networks shall provide one or more of these classes. These classes are defined in
- ' 3.2.3.1 and ' 3.2.3.2 with the following exceptions:
- V The terms used in ' 3.2.3.1 apply by replacing SPHT with SAUT.
- V Only the BVchannel access will be used in this case.
- V Mapping of information in the conditional case is restricted to the
- information elements available for endVtoVend transfer of information.
- 3.2 Access to the ISDN virtual circuit service (Case B)
- Interworking considerations are defined in ' 5.
- 3.2.1 Service characteristics
- The virtual circuit service provided within the ISDN is aligned with what
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- is described in the XVSeries Recommendations (e.g., in terms of facilities,
- quality of service, etc.).
- The service and facilities provided as well as the quality of service
- characteristics are those of the ISDN. Existing features of the XVSeries
- Recommendation may be enhanced and additional features may also be developed
- taking into account the new ISDN customer capabilities. A number from the ISDN
- numbering plan will be associated with one or more TA/TE1 (see Recommendation
- E.164).
- 3.2.2 User access capabilities
- In this case both BV and DVchannels can be used for accessing the ISDN
- virtual circuit service.
- 3.2.2.1 Access through the BVchannel
- 3.2.2.1.1 Service limitations
- In this case DTEs belonging to user classes of service 8 to 11, 13 and 30
- of Recommendation X.1 (categories of access T1 to T5 and Y1 to Y5 of
- Recommendation X.10) can be supported with no restrictions on the use of
- Recommendation X.25. The rate adaption mechanisms for user classes of service 8
- to 11 (access categories T1 to T4 and Y1 to Y4) as well as the TA functionalities
- are described in ' 7.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 3.2.2.1.2 Basic rules
- Packet data communications, when using a switched B-channel, will be
- established by separating the establishment phase of the B-channel and the
- control phase of the virtual circuits using the X.25 protocol (link layer and
- packet layer).
- In general, an ISDN has no knowledge of the customer's terminal equipment
- or configuration. In the demand access case the incoming B-channel connection
- establishment will have to employ the signalling procedures of S 6 (see
- Recommendation Q.931).
- 3.2.2.2 Access through the D-channel
- 3.2.2.2.1 Service limitations
- In this case DTEs belonging to user classes of service 8 to 10 of
- Recommendation X.1 (categories of access U1 to U4 of Recommendation X.10) and
- except on basic access user class of service 11 of Recommendation X.1 (categories
- of access U5 of Recommendation X.10) can be supported subject to the limitation
- imposed by LAPD as regards the maximum I-field length of the information frames
- (parameter N201 as defined in Recommendation Q.921). In any case, the maximum
- limit for the size of each frame to be transferred on the D-channel shall be 260
- octets.
- 3.2.2.2.2 Basic rules
- The following principles must always be respected in order to offer TE
- access to the PSDTS as it is defined in the Series X Recommendations,
- particularly X.25.
- A single SAPI = 16 LAPD link, as viewed by both the network and the user,
- must support multiplexing of logical channels at layer 3. Additionally, because
- the user may have a multipoint access, and because a single TA or TE1 is allowed
- to operate with more than one TEI, the network must support the presence of
- multiple SAPI = 16 LAPD logical links simultaneously operating at layer 2. This
- results in the requirement that the network be able to support simultaneous layer
- 2 and layer 3 multiplexing for D-channel packet mode connections.
- All X.25 packets, including call request and incoming call packets, must
- be transported to and from the TE in numbered information (I frames) in a SAPI =
- 16 LAPD link.
- An incoming call packet will be transmitted to a TE only after the public
- networks check at least the following:
- - compatibility of user facilities contained in the incoming call packet
- with the called subscriber profile when present;
- - availability of the logical channel, either two-way or incoming, on
- which the incoming call packet is sent.
- 3.2.3 Notification classes for incoming calls
- There are three classes in terms of Q.931 procedures to notify the user of
- incoming calls. These classes may be provided on a subscription basis. Networks
- shall provide one or more of these classes.
- 3.2.3.1 No notification class
- The network shall allocate incoming calls to a channel (D/B) using a
- network implemented algorithm. No Q.931 procedures are used to notify the user of
- incoming calls. Two subclasses are recognized:
- a) Semi-permanent (nailed-up) connections to the PH. An incoming call
- packet will be directly delivered over the semi-permanent connection.
- b) User initiated demand connections (at the called side)
- pr
- procedures. If the user has not initiated channels to the PH, the
- network shall clear incoming calls.
- 3.2.3.2 Conditional notification class
- Q.931 procedures are only used by the network to activate a channel for
- delivery of an incoming call when there is no available channel in the active
- state as defined in Recommendation Q.931. Subsequent incoming calls to the same
- ISDN number will be delivered over this channel without using Q.931 procedures.
- Some networks may have the ability to maintain information related to the
- state of the user's packet access channel. The network may apply an algorithm to
- determine that no additional calls should be added to the active packet access
- channel. The network may then reject the call immediately or use Q.931 procedures
- in an attempt to activate another channel for the purpose of delivering
- additional calls.
- Note V Some network may also compare the subaddress and use Q.931
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- procedure when the ISDN address differs from the ISDN address of the terminal
- with the active packet access channel.
- 3.2.3.3 Unconditional notification class
- Q.931 procedures are used by the network to notify the user of each X.25
- incoming call. As Table 3V1/X.31 notes, all of the information that is able to be
- copied from the X.25 incoming call packet to the Q.931 SETUP message is copied.
- This service is provided in order to aid the terminal equipment in the management
- of the interface (e.g., compatibility checking, channel selection).
- 3.2.3.4 Information mapping from the X.25 incoming call packet to the Q.931
- message
- In case of the conditional notification and unconditional notification
- classes, some of the information present in the X.25 incoming call packet should
- be mapped into the Q.931 SETUP message as indicated in Table 3V1/X.31.
- 3.3 Compatibility checking
- This paragraph is relevant for both Case A and Case B services.
- Information subject to compatibility checking in the public network(s), in
- the terminal systems, or in both the public network(s) and the terminal systems
- when establishing a communication between two systems can be divided into two
- basic capabilities:
- V The transmission capability may include ISDN network connection types,
- bearer service identification information bearer service identification
- information in relation to layers 1 to 3 in the terminals,
- and facilities defined in Recommendation X.2.
- V The communication capability involves higher layer
- functions for standardized applications in relation to
- telecommunication services. Other information, which is
- passed transparently between the terminal systems, may also
- form part of the communication capability. The coding of
- the information elements for compatibility checking and
- their relation to the open systems interconnection (OSI)
- reference model is in Recommendations Q.931 and X.300.
- Communication capability checking at the ISDN network
- connection level is limited to those parameters conveyable
- by the X.25 packet layer protocols, i.e., higher layer
- compatibility parameters cannot be passed from the calling
- user to the called user.
- TABLE 3V1/X.31
- Information mapping requirements for notification classes
- Notification class Information mapping
- Conditional notification Called address M
- Called subaddress M
- Any others O
- Unconditional All (Notes 1, 2) M
- notification
- M Mandatory
- O Network option
- Note 1 - "All" means as many as possible using available information
- elements shown in Table 6.4/X.31.
- Note 2 - Mapping may be restricted by length limitations of the SETUP
- message in Recommenda-tion Q.931. In case of a mandatory mapping, this
- restriction will result in clearing of the call. In case of an optional
- mapping, or length limitation violation, the selection of individual
- information elements to be mapped is network dependent, and will not
- result in clearing of the call.
- The network provides the transmission capability and furnishes the
- associated bearer capability information element to the user in the Q.931 SETUP
- message when the incoming call is notified to the user. This element and possibly
- others are used by the user equipment for compatibility checking purposes as
- described in Recommendation Q.931, Annex B.
- The network does not transmit any communication capability (i.e., the
- associated high layer compatibility information element) to the user since an
- X.25 packet layer protocol cannot transfer such an information element from the
- calling to the called user.
- 4 Addressing and routing aspects
- 4.1 Terminal interface selection
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- This section describes the information necessary to select a compatible
- TA/TE1 for the completion of an incoming call since users may operate several
- packet terminals in their multiservice arrangements.
- For data transmission, it is envisaged that an ISDN would identify, by
- means of an ISDN address, a specific interface within the subscriber premises.
- The transmission capability information may be used by the called TA/TE1 for
- compatibility checking purposes.
- Note - The terminal identification for PVC services is for further study.
- specifi
- specific terminal within a user installation.
- 4.2 Access to PSPDN services (Case \A)
- 4.2.1 Channel type selection
- Packet calls using this bearer service (i.e., circuitVmode) will always
- use the BVchannel.
- 4.2.2 Addressing scheme for outgoing calls
- The Q.931 SETUP message, when used, contains the request for a
- circuitVmode bearer service. The SETUP message also contains the ISDN address of
- the AU of the PSPDN.
- The X.25 call request packet contains the address of the called terminal.
- 4.3 Access to the ISDN virtualVcircuit service (Case B)
- 4.3.1 Channel type selection
- Two procedures are available regarding the manner in which channel type
- selection (ie., selecting between the BV and DVchannel type) can be performed@
- i) the terminal which is to accept the call will indicate the channel type
- to be used;
- ii) the ISDN has information on which channel type will be used for the
- incoming call.
- The various sorts of information that the ISDN may use to determine the
- channel may include, but are not limited to:
- a) subscription time agreements;
- b) occupancy level on established channels.
- Channel negotiation procedures may be found in ' 6.
- 4.3.2 Addressing scheme for outgoing calls
- The Q.931 SETUP message, when used, contains the request for the ISDN
- virtual circuit service. The SETUP message does not contain an address.
- The X.25 call request packet contains the address of the called terminal.
- 5 Interworking with dedicated networks
- 5.1 CircuitVmode access to PSPDN services (Case A)
- Interworking by port accessInterworking by port access (see
- Recommendation X.300) applies, i.e. the packet mode terminal
- accesses the PSPDN access port (AU) by use of a 64 kbit/s
- connection through the ISDN. The AU belongs to the PSPDN and is
- functionally equal to the interworking function (IWF) (see
- Recommendation X.325).
- 5.2 Access to PSPDNs via virtual circuit service (Case B)
- i.
- i.e. interworking between the ISDN and PSPDN is effected using X.75 or a
- functionally equivalent internal network protocol. In some implementations, the
- PH functions logically belonging to the ISDN may reside physically in a node of
- the PSPDN. The service provided is still the ISDN virtual circuit service. In any
- case, interworking between network providers is effected through use of X.75. See
- also Recommendation X.325.
- 6 Packet communications at the S/T reference point
- This section describes the information flows necessary to support packet
- communication over:
- a) circuit mode (Case A) operation on BVchannels; and
- b) packet mode (Case B) operation on BV and DVchannels of an ISDN access
- line.
- The ISDN TA/TE1 presents an S/T reference point towards the network and
- therefore the TA/TE1 implementation should embody the procedures described in
- Recommendations Q.921 and Q.931 for BV and DVchannel connection establishment and
- control. The protocol and the text of '' 6.1V6.5 and Appendix II of
- Recommendation Q.931, and '' 6.1V6.5 and Appendix III of Recommendation X.31 are
- identical.
- For demand access connections, '' 6.1 through 6.4 apply. Example message
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- flows for demand access connections are shown in Appendix III.
- Two types of semiVpermanent connections on BV and DVchannels are covered
- in this Section:
- 1) physical layer semiVpermanently established between the terminal and
- the PH/AU, i.e., the I.430/I.431 physical layer remains activated and
- the physical path through the ISDN is connected semiVpermanently; and
- 2) data link and physical layers semiVpermanently established between the
- terminal and the PH/AU (in this type, the network shall keep the data
- link layer in the established state).
- When a PVC is used, there must exist a type 2) semiVpermanent connection.
- In semiVpermanent connection type 1), the procedures of ' 6.3 are followed
- for call establishment and release.
- In semiVpermanent connection type 2), only the procedures of ' 6.3.2 are
- followed for call establishment and release.
- When semiVpermanent connection type 2) is used for PVCs, none of the
- following procedures apply.
- SemiVpermanent connections are established via a provisioning process
- without Q.931 procedures.
- 6.1 Outgoing access
- If the user selects an already established channel for the outgoing
- virtual call, then the procedures described in ' 6.3 apply. If the selected
- channel is not established to the AU/PH, then the procedures for activating a
- channel described in the following subsections are to be used before establishing
- the virtual call using the procedures of ' 6.3.
- For outgoing data calls, the user first must decide whether
- circuitVswitched (Case A) or packet switched services (Case B) are desired from
- the network. For outgoing circuit calls, the user follows the procedures of '
- 6.1.1. For outgoing packet calls, a user decides whether BVchannel or DVchannel
- is to be used for the packet call. If the user decides to use the BVchannel, then
- the procedures described in ' 6.1.2.1 are used. If the user decides to use the
- DVchannel, then the procedures described in ' 6.1.2.2 are used.
- Note - Some networks may not support every type of access. In the case of
- B-channel access, the network will clear a request for unsupported services by
- sending a RELEASE COMPLETE message with cause ##65, "bearer service not
- implemented". In the case of a request for D-channel access (an SABME with SAPI =
- 16), on a network port which does not support the service, no response is
- required of the network.
- 6.1.1 Circuit-switched access to PSPDN services (Case A)
- The B-channel connection between the user and the AU shall be controlled
- using the D-channel signalling procedures for call establishment described in S
- 5.1 of Recommendation Q.931. The specific B-channel to be used as a switched
- connection is selected using the channel selection procedures described in S
- 5.1.2 of Recommendation Q.931 and summarized in Table 6-1/X.31.
- TABLE 6-1/X.31
- User requested channel and network response
- Outgoing access to either an AU or PH
- Channel indicated in the SETUP message user to Allowable network
- network direction response
- network-user
- Chann Preferred or D-channel
- el exclusive indication
- indic
- ation
- Exclusive No Bi
- Bi Preferred No Bi, Bi`
- Any (Ignore) No Bi`
- (Absent) Bi`
- Bi the indicated (idle) B-channel
- Bi` any (other) idle B-channel
- Note 1 - All other encodings are invalid.
- Note 2 - All columns under the heading "Channel indicated in the SETUP message"
- indicate possible user codings of the Channel indentification information element
- contained in the SETUP message sent by the user to the network requesting a
- connection to an AU or PH (see Section 4.5.13 of Recommendation Q.931). The
- column under "Allowable network response" refers to the allowable responses by
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- the network to the user.
- On the basis of the call set-up information (e.g., called party number
- identifying an AU, transit network selection, etc.) and/or a subscription time
- agreement, the network provides a connection to the appropriate AU. The bearer
- capability information element included in the SETUP message shall be coded with:
- - information transfer capability set to either:
- a) "unrestricted digital information"; or
- b) "restricted digital information".
- - transfer mode set to "circuit mode";
- - information rate set to "64 kbit/s".
- Note - Bearer capability information element octets 4a and 4b shall not be
- included.
- The user may also specify the layer 1 (e.g., rate adaption), layer 2
- (i.e., LAPB), and layer 3 (i.e., X.25) information transfer protocols in the low
- layer compatibility information element in the SETUP message (see Annex to Q.931
- entitled "Low layer information coding principles").
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- 6.1.2 Access to the ISDN virtual circuit service (Case B)
- 6.1.2.1 B-channel
- Demand access B-channel connections are controlled using the D-channel
- signalling procedures for call establishment described in S 5.1 of Recommendation
- Q.931 using the messages defined in S 3.2 of Recommendation Q.931 with the
- following exceptions:
- - The procedures for overlap sending specified in S 5.1.3 of
- Recommendation Q.931 do not apply.
- - The procedures for call proceeding and overlap sending specified in S
- 5.1.5.2 of Recommendation Q.931 do not apply.
- - The procedures for notification of interworking at the origination
- interface specified in S 5.1.6 of Recommendation Q.931 do not apply.
- - The procedures for call confirmation indication specified in S 5.1.7 of
- Recommendation Q.931 do not apply.
- - The procedures for call connected specified in S 5.1.8 of
- Recommendation Q.931 apply as follows:
- - upon accepting the access connection, the network shall send a
- CONNECT message across the user-network interface to the calling
- user and enter the active state;
- - this message indicates to the calling user that an access
- connection to the packet handler has been established;
- - on receipt of the CONNECT message, the calling user shall stop
- timer T310 (see Recommenda-tion Q.931), may optionally send a
- CONNECT ACKNOWLEDGE message, and shall enter the active state.
- - The procedures for call rejection specified in S 5.1.9 of
- Recommendation Q.931 apply as follows:
- - when unable to accept the access connection, the network shall
- initiate call clearing at the originating user-network interface as
- described in S 5.3 of Recommendation Q.931.
- - The procedures for transit network selection specified in S 5.1.10 of
- Recommendation Q.931 do not apply.
- The specific B-channel to be used as a demand connection is selected using
- the channel selection procedures described in S 5.1.2 of Recommendation Q.931 and
- summarized in Table 6-1/X.31.
- For a demand connection to an ISDN PH, the bearer capability information
- element included in the SETUP message shall be coded with:
- - information transfer capability set to "unrestricted digital
- information";
- - transfer mode set to "packet mode";
- - information transfer rate set to 00000;
- - user information layer 2 protocol set to "Recommendation X.25, link
- layer";
- - user information layer 3 protocol set to "Recommendation X.25, packet
- layer".
- Note - Octets 4a, 4b and 5a, 5b, 5c, 5d shall not be included.
- The demand access connection can then be used to support packet
- communications according to X.25 link layer and X.25 packet layer procedures as
- specified in S 6.3.
- 6.1.2.2 D-channel
- communicatio
- communications according to X.25 layer 3 procedures as defined in ' 6.3. The X.25
- packet layer uses the acknowledged information transfer service (i.e., IVframes)
- provided by LAPD (see Recommendation Q.920). Consequently Q.931 procedures are
- not required to provide DVchannel access.
- A number of packet mode user equipment can operate simultaneously over the
- DVchannel, each using a separate layer 2 data link identified by an appropriate
- address (see Recommendation Q.921) in frames transferred between the user and PH.
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 6.2 Incoming access
- 6.2.1 Access from PSPDN services (Case A)
- The ISDN signals the establishment of the circuit-mode connection using
- the procedures described in S 5.2 of Recommendation Q.931. The virtual calls are
- signalled between the user and the AU using the procedures described in S 6.3.
- 6.2.1.1 General
- The general procedures performed by the AU are those defined in
- Recommendation X.32.
- 6.2.1.2 Channel selection
- If the physical circuit desired by the AU does not exist between the
- terminal and the AU, the procedures for physical channel establishment described
- in the following sections apply.
- The format of the SETUP message sent by the network to the user is in
- accordance with S 3.1 of Recommendation Q.931.
- The bearer capability information element included in SETUP message shall
- be coded with:
- - information transfer capability set to either:
- a) "unrestricted digital information"; or
- b) "restricted digital information".
- - transfer mode set to "circuit mode";
- - information rate set to "64 kbit/s".
- Note - Bearer capability information element octets 4a and 4b shall not be
- included. The channel identification information element shall be coded according
- to Table 6-2/X.31.
- TABLE 6-2/X.31
- Network requested channel and user response
- Incoming access from an AU
- Channel indicated in the SETUP message user to Allowable network
- network direction response
- network-user
- Chann Preferred or D-channel
- el exclusive indication
- indic
- ation
- Bi Exclusive No Bi
- Bi Preferred No Bi, Bi` (Note 1)
- Bi indicated (idle) B-channel
- Bi` any another idle B-channel (not permitted for broadcast call offering)
- Note 1 - This encoding is not used for broadcast call offering.
- Note 2 - All other encodings are invalid.
- The B-channel connection to the called user shall be established by the
- network using the signalling procedures described in S 5.2 of Recommendation
- Q.931. The call is offered by sending the SETUP message on a point-to-point data
- link or on the broadcast data link.
- The user responds to the SETUP as specified in S 5 of Recommendation
- Q.931.
- 6.2.2 Access from the ISDN virtual circuit service (Case B)
- To offer an incoming call, the network must perform the following steps in
- sequence:
- 1) Channel selection - the physical channel/logical link to be used for
- the incoming call must be identified. The network may use customer
- profile information, network resources, etc., to choose the channel, or
- the procedures in Step 2 below.
- 2) Physical channel/logical link establishment - if the physical B-channel
- or the logical link of the D-channel have not been determined by Step
- 1, the network may use the procedures in S 6.2.2.3. The network may
- then proceed with Step 3.
- 3) Virtual call establishment - the network establishes the virtual call
- using the procedures described in S 6.3.
- In the configuration for the ISDN virtual circuit service, the choice of
- channel type to be used for the delivery of a new incoming call packet shall be
- made by the network as described below.
- 1) A new incoming call packet may be indicated to the ISDN customer by a
- call offering procedure between the network and all user packet mode
- terminals (see SS 3.2.3.2 and 3.2.3.3).
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- 2) An incoming virtual call directed to a terminal with an established
- connection to the PH may be offered directly to the terminal over the
- established access connection without the use of Q.931 call offering
- procedures (see SS 3.2.3.1 and 3.2.3.2 of Recommendation X.31).
- 6.2.2.1 B-channel
- When calls are to be offered on the B-channels without channel
- negotiation, the procedures described in S 5.2 of Recommendation Q.931 using the
- messages of S 3.2 of Recommendation Q.931 apply with the following exceptions:
- - The procedures for overlap receiving specified in S 5.2.4 of
- Recommendation Q.931 do not apply.
- - The procedures for receipt of CALL PROCEEDING and ALERTING specified in
- S 5.2.5.2 of Recommendation Q.931 apply with the following exception:
- - the receipt of an ALERTING message shall not cause the network to
- send a corresponding ALERTING message to the calling user.
- - The procedures for call failure specified in S 5.2.5.3 of
- Recommendation Q.931 apply with the following note:
- - the network clears the incoming X.25 virtual call towards the
- calling X.25 DTE using the appropriate cause from Table 6-5/X.31.
- - The procedures for notification of interworking at the terminating
- interface specified in S 5.2.6 of Recommendation Q.931 apply with the
- following exceptions:
- - the case of the call entering an ISDN environment during call
- establishment is not applicable;
- party
- party;
- V the case of inVband information/patterns is not applicable.
- V The procedures for active indication specified in ' 5.2.8 of
- Recommendation Q.931 apply with the following exception:
- V the network shall not initiate procedures to send a CONNECT message
- towards the calling user.
- V The procedures for user notification specified in ' 5.2.10 of
- Recommendation Q.931 do not apply.
- Where an established BVchannel connection is to be used, the incoming call
- packet will be delivered in accordance with ' 6.3.
- Where a new BVchannel connection is to be established, the identity of the
- selected user will be associated with the Connection Endpoint Suffix (CES) from
- which the first CONNECT message has been received.
- 6.2.2.2 DVchannel
- The DVchannel provides a connection which enables the ISDN PH to access an
- ISDN user terminal or vice versa. This access is accomplished by establishing a
- link layer connection (SAPI = 16) to the terminal or network which can then be
- used to support packet communications according to X.25 layer 3 procedures as
- defined in ' 6.3.
- The layer 2 procedures shall be in accordance with Recommendation Q.921.
- The DVchannel provides a semiVpermanent connection for packet access since all
- layer 2 frames containing a packet mode SAPI (16) are routed automatically
- between the user and the PH function.
- When an incoming call is offered to packet mode user equipment at the user
- interface, the channel selection procedures described in ' 6.2.2.3 shall be used.
- A number of packet mode terminals can operate simultaneously over the
- DVchannel, each using a separate layer 2 link identified by an appropiate TE1
- (see Recommendation Q.921) in frames transferred between the terminal and the
- network.
- 6.2.2.3 Call offering
- 6.2.2.3.1 Channel selection through call offering
- The call offering procedure is performed using the layer 3 messages and
- procedures of ' 5 of Recommendation Q.931. The call offering procedure is
- integrated into the circuitVswitched call control procedures, signalled on the
- DVchannel, with the channel selection being accomplished by means of the channel
- selection procedure if offered as a network option.
- As described in ' 5 of Recommendation Q.931, the network selects the first
- user which responds to the call offering with a CONNECT message. When the
- selected user has requested that the X.25 call be set up over a new BVchannel,
- the network will indicate that the channel is acceptable by returning a CONNECT
- ACKNOWLEDGE message to the user. If multiple terminals have responded positively
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- to the SETUP message, the network shall clear each of the nonVselected terminals
- with a RELEASE message containing cause ## 26, SnonVselected user clearingT.
- t
- the selected channel.
- Note 1 V There is no time significance between the delivery of the RELEASE
- message and the incoming call packet, i.e., either may occur first.
- Note 2 V The network shall send the RELEASE message(s) and the user(s)
- shall respond with RELEASE COMPLETE.
- If the channel indicated by the first positively responding user is not
- available, the network will use Q.931 call clearing procedures to clear the call
- with cause ## 6, Schannel unacceptableT. If the channel indicated in the SETUP
- message is not acceptable to the user, the user will clear the call with a
- RELEASE message containing cause ## 34, Sno circuit/channel availableT or cause
- ## 44, Srequested circuit/channel not availableT.
- On the basis of a network option or subscription agreement, the network
- may choose the access channel or access channel type (e.g., B or D) for a
- particular incoming packet call.
- When the channel indication information element indicates Channel
- indication = No channel, Exclusive, and DVchannel indication = Yes, then the
- bearer capability information element should be encoded as follows:
- V Information transfer capability set to either: Unrestricted digital
- information or restricted digital information.
- V Transfer mode set to: packet mode.
- V Information rate set to: packet mode (00000).
- V Layer 2 protocol set to: Recommendation Q.921.
- V Layer 3 protocol set to: Recommendation X.25 packet layer.
- In all other cases, the bearer capability information element should be
- encoded as follows:
- V Information transfer capability set to either: Unrestricted digital
- information or restricted digital information.
- V Transfer mode set to: packet mode.
- V Information rate set to: packet mode (00000).
- V Layer 2 protocol set to: Recommendation X.25 link layer.
- V Layer 3 protocol set to: Recommendation X.25 packet layer.
- There exists an understanding that if the terminal responds with DVchannel
- indication set (see
- Table 6V3/X.31), the Layer 2 protocol to be used is Recommendation Q.921 (LAPD).
- The channel selection procedure for incoming calls is independent of the
- type of channel selected at the calling end. In this respect, any combination of
- channel type used at each end is possible, provided the user rates and available
- bandwidth are compatible.
- The channel selection principle to be used in the procedure is shown in
- Table 6V3/X.31.
- Note 3 V When the incoming SETUP message is sent on a broadcast data link
- with a channel identification information element which indicates an idle
- BVchannel and SpreferredT, the called user is not permitted to respond with a
- different idle BVchannel in the response. The option to respond with a different
- idle channel is restricted to pointVtoVpoint call offerings.
- so
- some networks, by subscription agreement, may offer SAPI = 16 broadcast call
- offering procedures for providing Q.931 signalling. This option shall use all
- Q.931 procedures for packet mode calls with the following restriction: All calls
- will be offered as SDVchannel exclusiveT and will not provide channel selection
- procedures. Terminals implementing SAPI = 16 procedures shall also implement SAPI
- = 0 procedures for portability.
- TABLE 6V3/X.31
- Network requested channel and user response
- Incoming access for packet mode
- Channel indicated in the SETUP message user to Allowable network
- network direction response
- network-user
- Chann Preferred or D-channel
- el exclusive indication
- indic
- ation
- No Bi
- Bi Exclusive Yes Bi, D
- No Bi, Bi`, Bj
- Bi
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- Preferred Yes Bi, Bi`, Bj, D
- No Bj
- No Preferred Yes Bj, D
- chann
- el
- Exclusive Yes D
- Bi indicated (idle) B-channel
- Bi` any other idle B-channel (not permitted in response to broadcast call
- offering)
- Bj an established B-channel under the user's control
- D the D-channel
- Note - All other encodings are invalid.
- 6.2.2.3.2 Information element mapping
- Q.9
- Q.931 information elements. The incoming call packet will still contain these
- fields when it is delivered. See ' 3.2.3 for mapping requirements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 6.2.2.3.3 Channel selection without call offering
- Where the network and user have agreed beforehand, the network may route
- an incoming call to the called user over an established B-channel connection or
- D-channel link without the need for any signalling for channel selection.
- 6.3 Virtual call establishment and release
- In all cases, once the physical channel has been selected and, if
- necessary, connected to the PH or AU, the virtual call is established according
- to the procedures below. Some networks may require some of the terminal
- identification procedures of Recommendation X.32 as well.
- 6.3.1 Link layer establishment and release
- Link layer (LAPB on the B-channel or LAPD on the D-channel) establishment
- shall be initiated by:
- - the calling terminal in the case of outgoing calls;
- - the AU in the case of incoming calls in Case A; or
- - the PH in the case of incoming calls in Case B.
- Link layer release may be initiated by:
- - the terminal;
- - the AU in Case A; or
- - the PH in Case B.
- 6.3.2 Packet layer virtual call SETUP and RELEASE
- The packet layer procedures of X.25 will be used for layer 3 call set-up
- and release. The packet layer procedures will additionally be able to control and
- monitor the established or released state of the link layer.
- In Case B, the PH may maintain a timer T320 (defined in Recommendation
- Q.931). T320, if implemented, is started:
- a) upon clearance of the last virtual call; or
- b) upon transmission of a CONNECT message by the network in case of an
- outgoing B-channel access connection; or
- c) upon transmission of a CONNECT ACKNOWLEDGE message by the network in
- case of an incoming B-channel access connection; or
- d) upon establishment of the link layer for D-channel access connections.
- T320 is cancelled upon:
- a) establishment of the first (next) virtual call; or
- b) receipt of a Q.931 clearing message from the user; or
- c) disconnection of the SAPI = 16 link on the D-channel.
- Upon expiry of T320, the PH will release the link layer and, in the case
- of B-channel access, initiate clearing of the B-channel.
- X.25 logical channels are associated with their underlying logical link.
- Specifically, in case of the use of the B-channel for packet communication there
- is an association between the logical channels and the LAPB logical link below
- them. Thus the same logical channel number may be used simultaneously on each
- different B-channel.
- 6.4 Call clearing
- 6.4.1 B-channel
- I
- ISDN virtual circuit service, the messages of ' 3.2 of Recommendation Q.931 are
- used, and the following exceptions apply:
- V the terms defined in ' 5.3.1 of Recommendation Q.931 STerminologyT
- apply by replacing ScircuitVswitched ISDN connectionT with Sdemand
- packet mode access connectionT;
- V the exception condition (f) specified in ' 5.3.2 of Recommendation
- Q.931 does not apply;
- V the procedures for clearing with tones and announcements provided in '
- 5.3.4.1 of Recommendation Q.931 do not apply.
- The BVchannel may be cleared at any time by the user though, in general,
- it will be cleared following the clearing of the last virtual call over that
- BVchannel. In the ISDN virtual circuit service, if the user clears the BVchannel
- access connection using a Q.931 clearing message while X.25 virtual calls still
- exist on the BVchannel, the network shall clear the X.25 virtual call(s) with
- cause ## 17, Sremote procedure errorT, and diagnostic ## 64, Scall setup, call
- clearing, or registration problemT.
- TABLE 6V4/X.31
- Mapping of X.25 information elements to corresponding Q.931 SETUP
- message information elements in packetVmode incoming call
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
-
-
-
-
-
-
-
-
-
- XFast select Packet layer binary parameters
- .
- 2
- 5
- uReverse charging For further study
- s
- e
- r
- f Closed user group selection For further study
- a
- c
- i
- l
- i
- t
- y
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
-
-
-
-
-
-
-
- DCalled address extension Called party sub-address
- T
- E
- F End-to-end transit delay End-to-end transit delay
- a
- c
- i
- l
- i
- t
- y
-
-
- Note 1 - Mapping is optional or required as indicated in S 3.2.3.
- Note 2 - The maximum length of the user data within the user-user information
- element is network dependent and is either 32 or 128 octets.
- Note 3 - The need and procedures for A-bit mapping is for further study.
- In Case B, if a Q.931 RESTART message is received by the PH during the
- X.25 data transfer phase, the X.25 virtual calls shall be treated as follows:
- - For switched virtual circuits, an X.25 clear indication packet shall be
- sent with cause ## 9, "out of order" and diagnostic ## 0, "no
- additional information".
- - For permanent virtual circuits, an X.25 reset packet shall be sent
- containing cause ## 9, "out of order" and diagnostic ## 0, "no
- additional information".
- At the expiration of timer T320, the network may disconnect the X.25 link
- layer and the access connection. B-channel clearing is as described in S 5.3 of
- Recommendation Q.931 with the exceptions above, with cause ## 102, "recovery on
- time expiry".
- 6.4.2 D-channel
- D-channel access connections are cleared using the disconnect procedures
- as defined in S 6.3.
- 6.4.3 Additional error handling information
- When call failure occurs, or the X.25 virtual call is cleared permanently,
- the rules of S 5.8 of Recommendation Q.931 shall apply. In addition, the
- following rules for determining the appropriate cause to be used shall apply in
- order of decreasing priority:
- 1) If a Q.931 clearing message or RESTART message is received by the PH
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- during the X.25 data transfer phase, S 6.4.1 applies.
- 2) If a call is rejected by the destination user using Q.931 messages, the
- X.25 virtual call shall be cleared using a clear indication packet and
- the appropriate cause from Table 6-5/X.31.
- 3) If a condition exists that prevents the Q.931 SETUP message from being
- delivered at the user-network interface, the X.25 virtual call shall be
- cleared using a clear indication packet and a cause shall be selected
- appropriate to the condition. Table 6-5/X.31 shall serve as a guide to
- selecting an appropriate cause, i.e., the X.25 mapping of the Q.931
- cause describing the interface condition shall be used.
- 4) If the Q.931 SETUP message is sent across the user-network iterface,
- but no response is received prior to the second expiry of timer T303
- (defined in Recommendation Q.931), rule ## 3 applies.
- 5) If the Q.931 SETUP message is sent across the user-network interface,
- and a response is received from a user which results in the clearing of
- the call at the user-network interface, the X.25 virtual call shall be
- cleared using a clear indication packet containing the appropriate
- cause from Table 6-5/X.31 relative to the cause received/sent in the
- Q.931 clearing message.
- 6) If an X.25 clear request packet is received from the originating user
- prior to the delivery of the X.25 incoming call packet to the called
- user (premature clearing), the PH shall send a clear configuration
- packet to the calling user and the access connection shall be treated
- as follows:
- - if the Q.931 SETUP message was associated with the unconditional
- notification class of service (see S 3.2.3), the access connection,
- when and if established, shall be cleared. The Q.931 clearing
- message shall contain the appropriate cause as described in Table
- 6-6/X.31;
- - if the Q.931 SETUP message was associated with the Conditional
- notification class of service (see S 3.2.3) and there exists at
- least one terminal which responds positively to the Q.931 SETUP
- message, then two options are allowed:
- a) the access connection is cleared as described for the
- unconditional class of service; or
- b) the access connection is established and timer T320 is started.
- Upon expiry of timer T320, the access connection is cleared with
- cause ## 102, "recovery on timer expiry" and diagnostic
- indicating timer T320.
- 6.4.4 Cause mappings
- 6.4.4.1 Access to/from PSPDN services (Case A)
- The AU may choose to follow the procedures in S 6.4.4.2 when mapping
- between causes delivered by the ISDN or the PSPDN.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 6.4.4.2 Access to/from the ISDN virtual circuit service (Case B)
- There are several cases where it is necessary to map causes between Q.931
- and X.25. Networks shall use Table 6-5/X.31 and Table 6-6/X.31 to map the causes
- between Q.931 and X.25 messages. The figures in Appendix III describe some
- example situations.
- 6.5 Access collision
- When the network offers a packet mode call at the interface simultaneously
- with the user requesting a packet mode call, the network shall give priority to
- the completion of the incoming call. If the user determines that accepting the
- incoming call would meet the needs of its own outgoing call request, the user may
- clear the call request and accept the incoming call.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- TABLE 6-5/X.31
- Mapping of Q.931 cause fields to X.25 cause field
- I Q.931 cause Cod Q. 931 X.25 Cause X.25 Cod
- t e Diagnostic Cod Diagnostic e
- e e
- m
- 1Unallocated 1 Condition: Not 13 Invalid called 67
-
-
-
- 2No route to 3 Condition: Not 13 Invalid 67
-
-
-
- 3Channel 6 (None) Remote 17 Call setup, 64
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 4Normal call 16 Condition: DTE 0 No additional 0
-
-
-
- 5User busy 17 (None) Number busy 1 No logical 71
-
-
- 6No user 18 (None) Remote 17 Call setup, 64
-
-
-
-
- 7User 19 (None) Remote 17 Call setup, 64
-
-
-
-
- 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
-
-
-
-
-
-
- 9Number 22 New Not 13 Invalid called 67
-
-
- 1Destination 27 (None) Out of order 9 No additional 0
- 0out of order information
- 1Invalid 28 (None) Local 19 Invalid called 67
- 1number format procedure address
-
-
- 1Normal,
- 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
-
-
- 1No 34 (None) Number busy 1 No logical 71
- 3circuit/chann channel
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- TABLE 6-5/X.31 (continued)
- Mapping of Q.931 cause fields to X.25 cause field
- IQ.931 cause Cod Q. 931 X.25 Cause Cod X.25 Cod
- t e Diagnostic e Diagnostic e
- e
- m
- 1Network out 38 (None) Out of order 9 No additional 0
- 4of order information
- 1Temporary 41 Network Out of order 9 No additional 0
- 5failure identity information
- 1Switching 42 Network Network 5 No additional 0
- 6equipment identity congestion information
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 1Requested 44 (None) Number busy 1 No logical 71
- 7circuit/chann channel
-
-
- 1Resources 47 (None) Nework 5 No additional 0
- 8unvailable, congestion information
-
- 1Quality of 49 Condition: Network 5 No additional 0
- 9service unknown, congestion information
-
-
- 2Bearer 57 Bearer Incompatible 33 No additional 0
- 0capability capability destination information
-
-
-
- 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- 1Bearer 58 Bearer Remote 17 Call setup, 64
-
-
-
-
- 2Service or 63 (None) Remote 17 Call setup, 64
- 2option procedure call clearing
-
-
-
- 2Bearer 65 Attribute Incompatible 33 No additional 0
- 3service not numbers destintion information
-
- 2Channel type 66 Channel type Remote 17 Call setup, 64
- 4not procedure call clearing
-
-
-
- 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 5Service or 79 (None) Remote 17 Call setup, 64
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- TABLE 6-5/X.31 (continued)
- Mapping of Q.931 cause fields to X.25 cause field
- I Q.931 cause Cod Q. 931 X.25 Cause Cod X.25 Cod
- t e Diagnostic e Diagnostic e
- e
- m
- 2Invalid call 81 (None) Remote 17 Call setup, 64
- 6reference procedure call clearing
-
-
-
- 2Identified 82 Channel Remote 17 Call setup, 64
- 7channel does identity procedure call clearing
-
-
-
- 2Incompatible 88 Incompatible Incompatible 33 No additional 0
- 8destination parameter destination information
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- 2Invalid 95 (None) Remote 17 Call setup, 64
- 9message, procedure call clearing
-
-
-
- 3Mandatory 96 Information Remote 17 Call setup, 64
- 0information element procedure call clearing
-
-
-
- 3Message type 97 Message type Remote 17 Call setup, 64
- 1non-existent procedure call clearing
-
-
-
- 3Message not 98 Message type Remote 17 Call setup, 64
- 2compatible procedure call clearing
-
-
-
-
-
-
- 3
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- 3Information 99 Information Remote 17 Call setup, 64
-
-
-
-
- 3Invalid 100 Information Remote 17 Call setup, 64
- 4information element procedure call clearing
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- TABLE 6-5/X.31 (continued)
- Mapping of Q.931 cause fields to X.25 cause field
- I Q.931 cause Cod Q. 931 X.25 Cause Cod X.25 Cod
- t e Diagnostic e Diagnostic e
- e
- m
- 3Message not 101 Message type Remote 17 Call setup, 64
- 5compatible procedure call clearing
-
-
-
- 3Recovery on 102 Timer number Remote 17 Call setup, 64
- 6timer expiry procedure call clearing
-
-
-
- 3Protocol 111 (None) Remote 17 Call setup, 64
- 7error, procedure call clearing
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- 3Interworking, 127 (None) Remote 17 Call setup, 64
- 8unspecified procedure call clearing
-
-
-
- Note 1 - When clearing occurs during the X.25 data transfer phase, the procedure
- described in S 6.4.1 should be used.
- Note 2 - When a Q.931 RESTART message is received during the X.25 data tranfer
- phase, switched virtual circuits shall be cleared with a clear indication packet
- containing cause ## 9, "Out of order", with diagnostic ## 0, "no additional
- information". Permanent virtual circuits shall have an X.25 reset packet sent
- with the same cause and diagnostic.
- TABLE 6-6/X.31
- Mapping of X.25 cause to Q.931 cause for premature clearing of the incoming call
-
- I X.25/X.96 cause Cod Diagnostic Cod Q.931 cause Code Diagnos
- t e e tic
- e
- m
- DTE originated 0 No additional 0 Normal call 16 (None)
- 1 information clearing
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
-
- 2Network 5 No additional 0 Switching 42 (None)
-
-
- 3Out of order 9 No addtional 0 Destination out 27 (None)
-
- 4Remote procedure 17 (Any allowed) Protocol error, 111 (None)
-
- Note - Instead of providing the above mapping of X.25 to Q.931, the PH, as a
- network option, may code the Q.931 Cause information element to indicate "CCITT
- Coding Standard" in octet 3, "X.25" in octet 3a, and code octets 4 and 5
- according to Recommendation X.25, copying the cause from the X.25 clear
- indication packet rather than mapping it to a Q.931 cause.
- 7 TERMINAL ADAPTOR FUNCTIONALITIES
- 7.1 General
- Terminal Adaptor (TA) functions are needed to support the access of X.25
- DTEs at the S/T reference point (see Figure 7-1/X.31).
- Fig. 7-1/X.31/T0702840-87 = 7 cm
-
- Main functionalities which are provided by the TA are the following:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- - rate adaption;
- - mapping of signalling information and procedures between the S/T and
- the reference point;
- - synchronization;
- - maintenance.
- Ca
- Case B).
- The procedures at the S/T reference point are described in ' 6.
- 7.2 Physical interfaces
- The physical interfaces supported at the R reference point are those
- defined in Recommendation X.25 Section 1, and Recommendation X.32.
- 7.3 Access through the BVchannel
- 7.3.1 General
- This part defines the functionalities to be supported by the TA when the
- access through the BVchannel is used. Both service Cases A and B are covered and
- differences, if any, are shown in the appropriate subparagraphs.
- 7.3.2 Rate adaption
- Rate adaption can be performed in two ways:
- 1) Packet mode of operation (Case B) by using HDLC interframe flag
- stuffing.
- In this case, packet mode terminals operating at data signalling rates
- lower than 64 kbit/s at the R reference point can no longer be
- distinguished by the network from packet mode terminals operating at a
- data rate of 64 kbit/s at the R interface.
- Therefore, the DVchannel signalling procedures will indicate the data
- signalling rate of 64 kbit/s rather than the user data signalling rate
- at the R reference point. In addition, a throughput class may be
- indicated in the DVchannel incoming call signalling procedures.
- It should be noted that the packet handling in the ISDN will be
- optimized for DTEs generating HDLC structured traffic at 64 kbit/s. In
- such an ISDN, flag stuffing is the preferred method for rate adaption.
- In order to avoid unnecessary retransmission on the BVchannel, the TA
- implementation could have a buffer capacity which is related to the
- layer 2 window size and maximum frame length or may flow control at
- layer 2.
- 2) Circuit mode of operation (Case A) by using the method indicated in
- Recommendation X.30/I.461.
- In this case, the DVchannel signalling procedures shall indicate the
- data signalling rate being used by the DTE connected to the R reference
- point (this will be lower than 64 kbit/s).
- As an alternative to HDLC interframe flag stuffing, this bit rate
- adaption method may be supported by some network in case of access to
- PSPDN services.
- Note V The use of VVSeries specification is for further study.
- 7.3.3 Signalling
- This part defines the functionalities to be supported by the TA to
- establish, maintain and release a BVchannel connection to the PH/AU. These
- functionalities require a different degree of capabilities by the TA on the basis
- of the different implementation of X.25 procedures in the DTE. Two cases can be
- identified, namely:
- Case 1: TA acts only on level 1
- Case 2: TA acts also on level 2 and/or 3
- The first case applies to X.25 DTEs which can disconnect at the physical
- level, when no VCs are in progress.
- For X.25 DTEs which are not able to disconnect at the physical level or
- even require an active link, the consequence of the first case may be the
- automatic allocation of the B-channel immediately after power on. To avoid this
- situation with a permanent allocated B-channel, an alternative configuration is
- presented in Appendix I.
- This section refers to signalling mapping of the first case.
- 7.3.3.1 Outgoing call
- To provide a physical connection by means of a B-channel to the PH or
- PSPDN AU the TA shall provide;
- - a method to indicate that the TA should start the B-channel
- establishment procedure at the S/T reference point. The options
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
- available are described in S 7.3.3.1.1,
- - a method to transfer address information to the TA which is needed by
- the B-channel establishment procedure. The options available are
- described in S 7.3.3.1.2.
- 7.3.3.1.1 Conditions for initiating B-channel establishment
- Two situations can be identified to categorize the conditions which may
- cause the TA to attempt to establish a B-channel connection.
- a) (semi-) permanent B-channel
- In this case, the B-channel is always available. No TA functionality is
- required to initiate the establishment of the B-channel connection.
- b) B-channel establishment is initiated by actions at the R-reference
- point (DTE/TA interface)
- Two conditions are possible. See Table 7-1/X.31.
- 1) Hot-line access at the R reference point
- In case of hot-line access at the R reference point the detection
- of the following appropriate interface conditions shall cause the
- TA to establish the B-channel with the PH/PSPDN.
- i) For X.25 level 1 interfaces - a transition from OFF to ON on the
- control lead (in case of X.21 leased circuit procedures) or
- circuit 108 (in case of X.21 bis or V-series interface
- procedures).
- ii) For X.21 interfaces - direct call signal (C = ON).
- The DTE will wait for I = ON before starting transmission.
- iii) For the X.21 bis interface - direct call signal (108 = ON).
- The DTE will wait for 107 = ON before starting transmission.
- iv) For the V.25 bis interface - direct call signal (108 = ON).
- The DTE will wait for 107 = ON before starting transmission.
- 2) Full circuit-switched selection access
- Full circuit-switched selection procedure (X.21, X.21 bis or V.25
- bis) may be used at the DTE/TA interface to request the
- establishment of the B-channel connection to a PSPDN or PH. The TA
- will establish the B-channel connection to a PSPDN or PH. The TA
- will establish the B-channel in accordance with the procedures
- described in Section 6. The address provided may be used to
- identify the PSPDN port and full X.25 procedures must be used
- following the establishment of the B-channel connection to identify
- the called packet mode DTE.
- in
- interface shall cause the TA to establish the BVchannel with the
- PH/PSPDN.
- i) For X.21 circuitVswitched interfaces V X.21 call control phase.
- ii) For X.21 bis circuitVswitched interfaces V use of X.21 bis
- automatic address call facility.
- iii) For V.25 bis circuitVswitched interfaces V V.25 bis addressed
- call mode.
- Note V The user may cause the TA to attempt to establish a BVchannel
- connection by manual actions (e.g., by pressing a button) at the human/machine
- interface of the TA. Subsequently the TA may emulate the incoming call towards
- the DTE.
- 7.3.3.1.2 Options for transferring the ISDN address of the PSPDN port to the TA
- Four options exist to handle address information of the PSPDN port at the
- TA:
- a) (SemiV) permanent BVchannel at the S/T reference point.
- In this case the TA has no need for address information, i.e., no
- functionality is required in the TA to obtain an address.
- b) The address is conveyed across the R reference point.
- In this case the circuitVswitched procedures described in ' 7.3.3.1.1
- b) 2) are required.
- c) The address is conveyed across the human/machine interface of the TA.
- Manual procedures are used (e.g., by means of a keypad) at the
- human/machine interface of the TA. The address may be input each time
- the BVchannel is requested. Alternatively the address may be stored at
- the TA (e.g., in the case of hot line operation at the R reference
- point).
- d) The address is downloaded by the network via the S/T reference point.
-
-
-
-
- PAGE30 Fascicle VIII.2 - Rec. X.31
-
- The need for this option is for further study.
- Note 1 V The address information may be for example a full ISDN address
- and abbreviated ISDN address, which is used by hotVline access procedures at the
- S/T reference point, or an abbreviated address which is interpreted by the TA and
- expanded to an (abbreviated) ISDN address using preVrecorded information in the
- TA.
- 7.3.3.1.3 Mapping of procedures
- The list of supported combinations and the appropriate procedures are
- given in Table 7V2/X.31.
- Following the establishment of the connection, the TA should place the R
- reference point in the appropriate condition for data transfer at layer 1.
- 7.3.3.1.4 Mapping of the Q.931 messages
- The procedures between the TA and the network are the same as described in
- ' 6. The choice of the requested service will be made by the appropriate coding
- of the bearer capability.
- In Case A the ISDN address of the PSPDN port will be introduced as the
- destination in the Q.931 message while in Case B no address is contained.
- 7.3.3.1.5 X.25 procedures
- existi
- existing LAPB establishment procedures (see Appendices I and IV).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.31 PAGE1
-
-